| Yazar |
Esnek Güç |
MD-C
Üyelik tarihi
26-02-2003
Mesajlar : 582
 OFF-Line
|  Yollanan 01-05-2004 at 17:18
DirectX için giriş seviyesinde bir dersi incelediğimde herşeyin; nesne tabanlı bir hiyerarşi ile ilerlediğini gördüm. OpenGL'de ise fonksiyonlarla. Bunu göz önünde bulundurursak Nesneye Dayayalı bir alt yapı ile DirectX mi? yoksa Fonksiyonlar ile OpenGL mi daha esnek ve güçlüdür?
Şimdi cevaplar arasında hemen, getirdiği avantajlar sayesinde nesneye dayalı programlama deyip yüzeysel cevaplar yazılabilir! ama böyle yazmayalım ve işin içine girerek, Nesneye dayalı yada Fonksiyolar ile sıkışıp kalınabilecek noktaları düşünerek cevap vermeye çalışalım...
|
|
|
 Profil
 www
 Düzenle
 Gönder
|
DoganBir
Üyelik tarihi
24-03-2003
Mesajlar : 7
OFF-Line
|  Yollanan 01-05-2004 at 17:41
Öncelikle şunu söyleyeyim. Nesneye dayalı programlama fonksiyonel olarak programlamanın ardından ortaya çıkmış ve bir çok şeyi daha rahat yapmamıza olanak veren güçlü bir sistemdir. Ve bugün programlama da kullanılan en iyi tekniklerden biridir. Bundan sonra çıkacak kavramdan da sizlere kısa bir bahsetmek isterim. Şu an ortada tam anlamıyla somut bir şeyler bulunmasada Aspect Oriented geliyor. Burada yapay zekayla iç içe geçmeye başlıyor artık. Sınıflarımız kendisi nesnelerini oluşturmaya başlıyor artık. Bundan sonra gideceğimiz nokta yapay zekadır. Artık herşeyi bizim yapmamızın gerekliliği ortadan kalkacak. Biraz uzaklaştım gibi. Kusura bakmayın.
Bu noktadan sonra ben fonksiyonel programlamaya dönmek niyetinde değilim. Object Oriented dan önce kullanırdım. Şimdi bir sınıf yazıp ardından bundan istediğim kadar nesne oluşturuyorum. Ardından gerekiyorsa Ana sınıfımdan alt sınıflar üreterek rahat ve esnek bir yapıya kavuşmuş oluyorum.
Yaşasın Object Oriented (Aspect Oriented gelsin artık.)
|
|
|
Profil
www
  Yolla
Düzenle
Gönder
|
MD-C
Üyelik tarihi
26-02-2003
Mesajlar : 582
OFF-Line
| Yollanan 01-05-2004 at 17:50
Yazdıkların doğru! heheh dediğim gibi yüzeysel baktık sanki olaya? Adamı sıkıyor bir nesneye bağlı kalıp ondan birşeyler çıkarmak? Hey şey ortada serbestsin Fonksiyonlar ile... Hepsi başıboş geziyor. Ne güzel  istediğini al ordan kullan... istediğin an istediğin tanımlamayı yap, yada yapmadan işleme başla....
|
|
|
Profil
www
Düzenle
Gönder
|
ferdemoncel
Üyelik tarihi
03-11-2003
Mesajlar : 97
OFF-Line
| Yollanan 01-05-2004 at 17:59
> Fonksiyolar ile sıkışıp kalınabilecek noktaları düşünerek ..
Bunu görünce direkt olarak benim aklıma windows programlama ve bunun yanında C fonksiyonlarının C++'nin güçlü nesnesel özelliklerinden faydalanarak kullanılması geliyor.
Şu adreste : http://www.relisoft.com/book/win/index.htm
C fonksiyonlarının C++'nin güçlü nesnesel özellikleri ile kullanılmasına dair örnekler bulmuştum. Sanırım aynı şey OGL fonksiyonları için de düşünülebilir.
Örneğin C++ çeşitli programlama türlerini destekleyen multi-paradigm bir dil olarak bilinir. Eğer elimizdeki program NYP'a yönelik bir çözüm gerektirmiyorsa fazla kasmaya gerek yok :) Ama ben yine de windows programlama ve OGL için C++'nin NYP destekleyen güçlü özelliklerinden faydalanmak gerekir diye düşünüyorum.
|
|
|
Profil
 E-posta
www
Düzenle
Gönder
|
chfbat
Üyelik tarihi
31-12-2003
Mesajlar : 46
OFF-Line
| Yollanan 01-05-2004 at 19:42
Tabiki DirectX çok daha güçlüdür.
Çünkü ekli olan özellikler çok fazla ve gerçekten hepsi çok iyi çalışıyor.
DirectFONT
DirectDraw
Direct3D
ses desteği ve daha fazlası...
Ve gerçekten öğrenmek için çok çaba harcadığım dillerden ikici Pixel/Vertex Shader dilleri. Çok rahatça kullanılabiliyor..
Yani directX profesyonel oyun yapımcıları için vazgeçilmezler arasında...
Mesela CAPS adlı struct'ı kullanarak ekran kartının bütün özelliklerini alıp optimizasyon yapabiliyorsunuz.
Eğer OpenGL'de fonksiyonları başlıklar altında sıralasaydı eminim altta kalır yönü olmayacaktı. Vede Ses ve Font desteği eklenirse...
|
|
|
Profil
E-posta
www
 Yolla
Düzenle
Gönder
|
mentat
Üyelik tarihi
15-10-2002
Mesajlar : 287
OFF-Line
| Yollanan 01-05-2004 at 19:47
oncelikle c fonksiyonel degil prosedurel bir dildir. fonksiyonel diller baska bir kavram..
aspect oriented de sanirim biraz ilgisiz kaliyor bu tartismada. sadece bir seminere takildim ve bir giris seviyesinde makale okudum aspect oriented konusunda, ancak benim anladigim, aspect oriented, proje yonetimi, tasarim meselelerine daha yakin. UML, XP, design by contract vs vs gibi yazilim muhendisligi meseleleriyle karsilastirilmali gibi geliyor bana. aspect oriented bir sekilde projenizi tasarlar ve gelistirirken, isterseniz NYP, isterseniz prosedurel paradigmalarla kodmaya devam edebilirsiniz..
gelelim ogl/dx'i NYP ve prosedurel olarak karsilastirmaya. bence gereksiz bir tartisma. ben NYP egilimliyim ve OGL kullaniyorum, ve dogal olarak OGL islemlerini yapan birsuru wrapper (turkcesini uyduramadim) sinifim var kendi yazdigim. kendi yapima monte etmek icin dx olsun gl olsun zaten bir sekilde kendi siniflarimi yazmam dogal. yani gl ile NYP takilabilirsiniz. ayni sekilde dx ile de prosedurel.
tam da bu noktada, pekcok GL'ci DX'i cirkin bulur (ben bulmam), MS'in NYP temellerle gelistirdigi yapiya eger c++'a hakim degilseniz alismak biraz guc. once c ile baslayip c++'a gecmeye karar veren zavalli sanssizlardansaniz bu daha da guc. dx size cok karisik gelir, bulasmak istemezsiniz. ama bu ne dx'in zayifligi, ne gl'in gucu. zaten boyle birsey de yok..
uzatmayayim.. gl ve dx iki API, iki kutuphane. butun dunya icigina cicigina, fanatizmle tartisiyor (az sonra sensei firlayip dx rulez diyebilir), tartismanin pek de bir manasi yok bence. hele nyp'nin bir api'ye ne getirdigi ne goturdugu birsey var, en azindan dx ozelinde..
|
|
|
Profil
E-posta
www
 Yolla
Düzenle
Gönder
|
mentat
Üyelik tarihi
15-10-2002
Mesajlar : 287
OFF-Line
| Yollanan 01-05-2004 at 19:50
chfbat: DirectFONT'u yeni duydum. dx10'da falan mi var bu? bi de DirectDraw DX7'den sonra kalkti diye biliyorum. bi de Caps ile kartin ozelliklerini alirsin da optimizasyon kismini anlamadim. gl ile de glGet* ile tum ozelliklere ulasirsin kartin, ve sonra glHint'le falan.. vs vs vs..
shader'lar konusuna ise katiliyorum. HLSL yazilarini bekliyorum (ben de ogrenmeye kasiyorum da).
|
|
|
Profil
E-posta
www
Yolla
Düzenle
Gönder
|
chfbat
Üyelik tarihi
31-12-2003
Mesajlar : 46
OFF-Line
| Yollanan 01-05-2004 at 19:55
Quote:
|
On 2004-05-01 19:50, mentat wrote:
chfbat: DirectFONT'u yeni duydum. dx10'da falan mi var bu? bi de DirectDraw DX7'den sonra kalkti diye biliyorum. bi de Caps ile kartin ozelliklerini alirsin da optimizasyon kismini anlamadim. gl ile de glGet* ile tum ozelliklere ulasirsin kartin, ve sonra glHint'le falan.. vs vs vs..
shader'lar konusuna ise katiliyorum. HLSL yazilarini bekliyorum (ben de ogrenmeye kasiyorum da).
|
|
yanlış yazdım yaa kusura bakmayın. oda önceden vardı. eski versiyonlarda farklı bir isimle çağırılıyordu. Visual Basic kullananların bilmesi gerekiyor.
glGet'i biliyorum. optimizasyondan kastımda default olarak ayarlanan başlangıç çözünürlük ayarlarının yazılım tarafından açılışta otomatik olarak şekillenmesi.
p/V shaders gelecek yakında merak etmeyin )
|
|
|
Profil
E-posta
www
Yolla
Düzenle
Gönder
|
DG
Üyelik tarihi
06-03-2004
Mesajlar : 59
OFF-Line
|  Yollanan 02-05-2004 at 02:51
En son bildiğim kadarıyla DirectX, Com+ nesne yapısıyla çalışıyordu. DirectX ile prosedürel programlama yapmak biraz kasıntı olur gibi geldi bana.
DirectX ile OpenGL kıyaslanmaz aslında (hangi dil altında ya da hangi programlama teknikleri kullanılmadığına bakılmaksızın). Bu Visual Studio .NET 2003 ile Visual C++ Toolkit i kıyaslamak gibi bir şey. OpenGL açılmış "rendering contex"'in içine birşeyler çizdirmekten başka bir şey yapmaz. DirectX ise oyun yapımına dair her türlü ihtiyacı karşılıyor. Bu bağlamda, Direct3D ile OpenGL'i kıyaslamak bile tam mümkün olmaz çünki Direct3D tümleşik olarak geldiği sistemin gücünü de yanına alıyor (pencere açma, doku işlemleri için stream oluşturma vs..) Olaya bu boyuttan bakıldığında DirectX kıyas götürmeyecek kadar zengin.
Prosedürel programlamayı izlemek çok zor oluyor. Ne kadar açıklama satırı yapılmış ya da "identation" olayına özen gösterilmiş olsa da, oyun gibi büyük işlerde kod çorbaya dönebiliyor (ben Q2'nin kodlarının büyük bir kısmını hala çözemiyorum) Prosedürel programlama ile bir yerlere sıkışıp kalabilirsin ama nesneye dayalı programlama ile öyle bir durum olacağını sanmıyorum (en azından günümüz için)
Konu DirectX'ten açılmışken. DirectX'in içinde gelen shader öğeleri ile NVIDIA'nın CG'si arasında ne fark var? FarCry'nin shaderları CG ile yapılmış (halbuki oyun DX9.0b istiyor), hatta Deus Ex 2'ninkiler de CG ile yapılmış (DX8.1 istiyor).
|
|
|
Profil
www
 Yolla
Düzenle
Gönder
|
cemuzunlar
Üyelik tarihi
03-08-2003
Mesajlar : 15
OFF-Line
| Yollanan 02-05-2004 at 04:19
>DG
>Konu DirectX'ten açılmışken. DirectX'in içinde gelen shader
>öğeleri ile NVIDIA'nın CG'si arasında ne fark var? FarCry'nin
>shaderları CG ile yapılmış (halbuki oyun DX9.0b istiyor),
>hatta Deus Ex 2'ninkiler de CG ile yapılmış (DX8.1 istiyor).
OpenGL'in de, DirectX'te verteks ve piksel shaderlari, temelde api'ye ozel assembly dilleri uzerine kurulu. Yani hicbir ust seviye dil kullanmadan( HLSL, CG, GLSL ), hem OpenGL'de hem de DirectX'te verteks ve piksel shaderlari kullanmak mumkun.
Ancak bu alt seviye diller ile shader programlamak cok guc oldugundan, bir sure once ust seviye diller'de apilere girdi. Burada bilinmesi gereken nokta su: Iki apide de ust seviye shader dilleri ile yazilan programlar, alt seviye assembly'e cevriliyorlar ve sonrasinda ekran kartinin surucusune gonderiliyorlar. Yani ekran kartinin tek anladigi bu alt seviye programciklar. Etrafta dolasan tum ust seviye shade dilleri bir sekilde kodunuzu derliyor ve alt seviye ciktilari kullaniminiz icin size veriyor. Hatta ust seviye dille yazdiginiz shader programciginin, derlentikten sonra olusan assembly halini bile gormeniz mumkun.
OpenGL'de verteks ve piksel shader'lari kullanmak icin ilk yol, alt seviye assembly ile shader programlayabildiginiz, ARB'nin onayladigi ARB_vertex_shader ve ARB_fragment_shader eklentileri. Bu eklentilerin olmadigi donemde ATI ve NVIDIA'nin,shader yazmaniza olanak veren kendi alt seviye assembly dil eklentileri vardi. Bunlar hala duruyor ama kullanimdan kalktigi soylenebilir. Ust seviye shader dili olarak, OpenGL 2.0 icerisinde yer almasi planlanan OpenGL Shading Language ( GLSL ) halen gelistirme asamasinda. Hatta yavas yavas ATI ve NVidia'nin suruculerinde GL_ARB_shading_language_100 ismiyle gelmeye basladi. GLSL ile yazdiginiz shader programciklari, GLSL derleyicisi tarafindan ARB_vertex_shader ve ARB_fragment_shader programciklarina donusturuluyor ve ekran karti tarafindan kullaniliyor.
DirectX'te alt seviye shader assembly dilleri ve High Level Shading Language ( HLSL ) isimli bir ust seviye shader programlama diline sahip. Burada da durum ayni. HLSL kodlariniz, HLSL derleyicisi tarafindan, assembly'ye cevrilerek surucuye yollaniyor.
CG de bir ust seviye shader programlama dili. Ozelligi hem DirectX hem de OpenGL destegi olmasi. Bu destegi soyle sagliyor. CG ile yazdiginiz ust seviye shader programciklari, CG derleyicisi tarafindan, seciminize bagli olarak,ister DirectX icerisindeki assembly shader programlama diline, isterseniz de OpenGL icerisindeki assembly shader programlama dillerine cevriliyor. Hatta daha da otesini yapabiliyor ama bunlar su an icin onemsiz detaylar. Bu sayede CG ile yazdiginiz shader'lari teorik olarak iki api'de de kullanabiliyorsunuz.
Ben bu yontemlerin tumunu deneyip test ettim. Ne alt seviye dillerin, ne de ust seviye dillerin aralarinda onemli bir fark oldugunu soyleyemem, buyuk olcude aynilar. Her iki api'de de assembly shader dilleri ile programlama yapmak cok zahmetli. Ancak ust seviye dillerde optimize kod yazabilmek ve ekran kartinin gercekte hangi ozellikleri, nasil destekledigini ogrenmek icin incelenmeleri gerekiyor. OpenGL kullandigim icin, GLSL derleyicileri son haline geldiklerinde, ust seviye dil olarak secimim bu olacak. Ancak su anda profesyonel kullanim icin hazir olmadiklari icin uzun suredir CG kullaniyorum. Derleyicisi cok cok saglam. Dokumantasyonu, ornekleri de oldukca iyi. Kullaniminda herhangi bir zorluk cekeceginizi sanmiyorum.
|
|
|
Profil
www
 Yolla
Düzenle
Gönder
|
